A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright(copyright) 2000, Microsoft Corporation, All Rights Reserved.
The present invention pertains to a unified event programming model that standardizes event programming for disparate eventing protocols. The unified event programming model includes standard event programming compiler constructs.
To manage the complexity of long computer programs, computer programmers often adopt object-oriented programming techniques. With these techniques, a computer program is organized as multiple smaller modules called objects. Each object performs specified functions and interacts with other objects in pre-defined ways. FIG. 1 shows several principles of object oriented programming with reference to an object 100 that interacts in pre-defined ways with a client 140 (which can also be an object)
The object 100 encapsulates data 110, which represents the current state of the object 100. The data 110 can be organized as data elements such as properties of the object 100. The object 100 exposes member functions (alternatively called methods) 120, 122, and 124 that provide access to the data 110 or provide some other defined function or service. To access the data 110, the client 140 of the object 100 calls a member function. In FIG. 1, the member functions 120, 122, 124 are grouped into an interface 126. FIG. 1 also includes an interface 130 (shown without member functions for simplicity).
The object 100 and the client 140 interact across the interfaces exposed by the object 100. For example, for the client 140 to invoke the member function 120, a function call in the client 140 identifies the member function 120, provides any data to be processed (e.g., input parameters for arguments), and indicates any data to be returned (e.g., output parameters for arguments, return values). Similarly, for the client 140 to set a value for a property of the data 110, the client 140 identifies the property and provides the value.
FIG. 1 shows a software object designed according to a particular object model. In fact, many different software object models exist, each establishing a set of conventions by which objects are designed and by which objects communicate. For example, an object model might specify how an interface is organized, how an object implements an interface, how an object exposes an interface to other objects, which methods are required, etc. Different object models provide different answers to these questions. A computer programmer can write code for a software object in any of numerous different programming languages.
Communication between objects can occur in two directions. For example, one object (an event receiver) can arrange with another object (an event source) to have that other object call back the first object when some event occurs. For example, suppose that the event receiver is for reacting to a mouse button clicked by a user and that the event source tracks the mouse button state. The event receiver can arrange with the event source to have the event source call back the event receiver when an event occurs. The event source calls back to the event receiver as the events happen, or asynchronously, rather than at a regular interval. A single event source can call back to multiple receivers registered for the event, in which case the callback is termed multicast.
Due to the effectiveness of events for object communication, many programming languages and software object models support events. Typically, each programming language and software object model has its own eventing protocol, and each of these eventing protocols has its own nuances and particular rules.
Different object models work best in different situations, so a programmer might need to know how to program for different kinds of objects. To use the eventing protocol for an object, however, a programmer must know the particular rules and nuances of that eventing protocol for that type of object. Unfortunately, no unified event programming model exists for programming an object to work with events according to different eventing protocols, independent of the actual eventing protocol used by the object for the events.
The present invention overcomes these problems through a unified event programming model [xe2x80x9cUEPMxe2x80x9d] that standardizes event programming for disparate eventing protocols. The UEPM provides a programmer with an easy to use and systematic way to program events for objects, regardless of which eventing protocol the objects actually use. This hides from the programmer the bulk of the eventing protocol-specific details relating to implementation of the objects.
The UEPM includes standard event programming compiler constructs. One construct allows a programmer to specify an eventing protocol for an object to use. For an event source object, a construct allows a programmer to indicate the event. For an event receiver object, constructs allow a programmer to indicate how to hook up the receiver to the source for the event, or later unhook the receiver. Using these constructs, a programmer can specify event relationships between an event source and an event receiver in a protocol-independent manner. From the constructs, the compiler generates a protocol-specific eventing implementation, which can be for any of several different eventing protocols. At compile time, the compiler can verify the existence of events and checks parameter types for receivers trying to hook to events. This type checking at compile time eliminates expensive run time type checking and simplifies debugging.
By allowing high-level specification of event relationships between objects, the UEPM also gives programmers a simple way to write objects of different object models that can interoperate for eventing.